D11 is about reinventing X11 for higher performance. This does not mean abandoning compatibility with the current X11 protocol or X11 semantics or network extensibility. Instead, D11 concentrates on optimizing the local window system interface. Programs compiled to support the D11 interface will operate with current X11 servers, and all X11 clients will operate unchanged with a D11 window system. The substantive difference is that D11 programs can achieve substantially better window system performance than equivalent X11 clients running locally.
The API for D11 is a superset of the X11 Xlib API. The D11 API is augmented with higher performance local interfaces for some existing Xlib operations. When a D11 program runs locally within the D11 framework, these interfaces allow window system operations to be performed in a manner optimized for the local case. When a D11 program runs remotely or connects to a local X11 server, the new D11 interfaces generate the X11 protocol to achieve the same effect at lower performance.
Figure 1: Calling and returning from a protected procedure call. The address
space mapping on top indicates the current active address space mapping.
The D11 implementation does not structure the window system service as a separate process that clients communicate with via X11 protocol byte streams. Instead, the X server is reimplemented via a user-level kernel facility called active contexts. Instead of writing and reading X protocol through bytes streams, D11 programs call the D11 window system directly through a protected procedure call mechanism. A protected procedure call is a change of execution state into an active context where the program's address space is augmented by the memory regions for the active context and the process's identity (including all standard Unix resources like file descriptors and signal handlers) is transformed into that of the D11 window system kernel. On return from a protected procedure call, the program identity and address space are restored. Figure 1 shows the effect of a protected procedure call on a process's address space and identity.
The active context facility is very much analogous to the Unix kernel's traditional implementation. In Unix, when a process traps into the kernel via a system call, the processor vectors to a well-defined kernel system call handler and then continues running at a higher privilege level with an address space augmented by the kernel's memory regions. An important distinction between a Unix kernel and the D11 active context is that threads of control within an active context execute in user mode like other Unix processes, not in kernel mode like the Unix kernel. Because of D11's kernel style architecture, what one would call the X server in X11 is called the window system kernel in D11.
Logically, a D11 program is subscribing to a service for window system functionality. Likewise, one could consider a Unix process to be subscribing to the Unix kernel for operating system services. While D11 does implement a service, we avoid the term ``client/server'' when describing D11 because it usually suggests an implementation style with the client and server implemented as distinct processes.
It is worth noting that many micro-kernel architectures have been implemented that take this notion of Unix as a service to the logical conclusion of implementing Unix as a server process and emulation libraries extracted from the kernel proper [11,14]. The advantage of a client/server structuring in separate address spaces is modularity and distributability. The advantage of kernel style structuring is less data transfer and lower context switching overhead for potentially better performance in tightly integrated systems (like local window systems) than a client/server implementation. The duality of client/server ``message-oriented'' structuring and kernel style ``procedure-oriented'' structuring has been recognized for some time [19]. Reimplementing X as D11 should provide further evidence of this duality.